要件定義 - 鼎談
――放課後の図書室。ノートPCを広げた三人。
ふーこ.icon（進行係）
はいはいみんな注目〜！今日のテーマは「要件定義」ね！
ぶっちゃけさ、これミスるとプロジェクト即・南無三ってやつじゃん？草。
ってことで、まずは「要件定義って何なん？」からいこ！
ましろ.icon（やさしく）
うん、いいね。
たとえば「便利なアプリを作りたい」だけじゃ足りなくて、
ひより.icon（淡々と）
補足すると、要件定義は“作る前の設計図の設計”だね。
いきなり作り始めると、目的と手段がズレる確率が高い。
統計的にも、システム開発の失敗原因の上位は「要件の不明確さ」とされている。 ふーこ.icon
出た、ひよりのデータ砲。つよい。
でもさ、現場って「とりあえず作ってみよ！」ってなりがちじゃん？
文化祭の出し物レベルでもそうだよね？
ましろ.icon
あるあるだね。
作り直しが大変になるの。
ひより.icon
コストが指数的に増える。
後からの変更は、早い段階の変更より数倍〜数十倍の手間がかかるという研究もある。
だから最初に決める価値が高い。
ふーこ.icon
つまりさ、「後から修正＝地獄」ってことね。了解。
じゃあさ、要件定義って具体的に何決めんの？
ひより.icon
大きく分けて二つ。
一つは「何をできるようにするか」。
もう一つは「どれくらいちゃんと動くべきか」。
ふーこ.icon
翻訳しまーす！
前者は「機能」ね。ボタン押したら投稿できる、とか。 後者は「性能」ね。サクサク動くとか、落ちないとか。 合ってる？
ひより.icon
正確。
ましろ.icon（微笑む）
ふーこ、わかりやすいね。
ふーこ.icon
先生は「簡単なサイト」って言うけど、生徒は「SNSみたいなやつ」想像してたり。
ひより.icon
認識のズレ。
人は自分の前提を言語化しない傾向がある。
だから質問が重要になる。
ましろ.icon
うんうん。
「簡単って、どれくらい？」
「誰が使うの？」
って、優しく確認するのが大事だね。
ふーこ.icon
要するに、空気読まずにガンガン聞けってことね。
「それって具体的には？」を連打。
コミュ力ゲーじゃん…。
ひより.icon
コミュニケーションは技術。
感覚ではなく、構造で考えられる。
目的→利用者→場面→必要な機能、の順に分解する。
ましろ.icon
ひよりの考え方、整理されていて好きだな。
上から順番に決めていくのね。
ふーこ.icon
いきなり「ボタン何色？」とか言い出すのは事故、と。
ひより.icon
優先順位が逆転している。
そこが曖昧だと、全部ブレる。
ましろ.icon（共感気味に）
でも、最初にそこまで考えるのって、ちょっと怖くない？
間違ってたらどうしよう、って。
ひより.icon
だから仮説として定義する。
絶対ではない。更新可能な前提。
ふーこ.icon
あー、それいいね。
「いったんこれでいこ！」って決めるけど、あとで見直せる前提。
固定じゃなくて、暫定。
ましろ.icon
完璧じゃなくていい、ってことだね。
ちゃんと話し合って決めた、という状態が大事なんだね。
ふーこ.icon（まとめに入る）
じゃあ今日の結論いくよ〜！
要件定義＝「何作るか」をちゃんと決めるターン
機能（何できる？）と性能（どれくらいちゃんと？）を分ける
ズレは起こる前提。質問しまくれ
目的から順に決める。いきなり細部はNG
完璧じゃなくていいけど、合意は必要
こんな感じ？
ひより.icon
妥当。
ましろ.icon（やわらかく笑う）
うん、とてもいいまとめだと思うよ。
最初に丁寧に決めることが、あとでみんなを助けるんだね。
ふーこ.icon
よし、これで文化祭アプリも爆死回避！
要件定義、ナメたらあかんやつでした〜！
三人、ノートを見つめながら次の議題へ。